Refs #961

Problem

When state.sqlite becomes corrupted (truncated, overwritten, or contains non-SQLite data), the backend server crashes immediately on startup. The desktop app then restarts the backend in a loop, producing endless backend exited unexpectedly (code=1) messages with no recovery path. Users are stuck unless they manually find and delete the database file.

The root cause is two-fold:

1. makeSqlitePersistenceLive in Sqlite.ts blindly passes the database path to the SQLite client with no pre-flight validation
2. NodeSqliteClient.ts calls openDatabase() as a bare synchronous call inside Effect.gen - when it throws, the error becomes an unhandled defect that crashes the process

Fix

Corruption detection and auto-recovery (Sqlite.ts)

Before opening the database, makeSqlitePersistenceLive now validates the file header. Every valid SQLite file starts with the 16-byte magic string SQLite format 3\0. If the file exists but has an invalid header:

• The corrupted file is renamed to state.sqlite.corrupted.<timestamp> (preserving it for debugging)
• Stale WAL and SHM journal files are cleaned up
• A warning is logged explaining what happened
• A fresh database is created and migrations run normally

Safety net for database open errors (NodeSqliteClient.ts)

The bare openDatabase() call is now wrapped in Effect.try with Effect.orDie, so any throw during database construction produces a properly reported defect with a clear "Failed to open database" message instead of an opaque crash.

Testing

Manually verified with a corrupted database file:

echo "not a db" > ~/.t3/userdata/state.sqlite
t3code

Before: crash loop, file is not a database repeated every ~500ms, process killed
After:

WARN: Corrupted database detected at /path/state.sqlite. Backing up to /path/state.sqlite.corrupted.1774012943326 and creating a fresh database. Session history will be reset.
INFO: Running migrations...
INFO: Migrations ran successfully

Header validation was also tested against:

• Corrupted file (garbage text) → detected, recovered
• Empty file (0 bytes) → detected, recovered
• Valid SQLite database → passes, opened normally
• Non-existent file → skipped, fresh database created

Scope

This is complementary to #964 (draft), which handles the web/UI recovery view for bootstrap snapshot failures. This PR fixes the server side so the backend never gets stuck in a crash loop.

Test plan

• Corrupt state.sqlite with echo "not a db" > ~/.t3/userdata/state.sqlite, start app, verify recovery
• Delete state.sqlite entirely, start app, verify fresh database is created
• Start app with a valid existing database, verify normal startup (no false positives)
• Verify backed up .corrupted.<timestamp> file is created alongside the new database